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ABSTRACT 



Group decision making utilizing the Delphi method can be 
a time-consuming and difficult procedure, especially when 
the required group membership is separated by great 
distances. This study designs and implements an automated 
group decision support system which may be employed by a 
single computer or a networking system. 

This particular model is text— based as opposed to 
mathemati cal -based , a radical departure from the GDSS models 
currently in vogue. This program. Touchstone, successfully 
translates the Delphi method of criteria development to the 
computer. It is implemented in Turbo Pascal for the IBM-PC. 
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I. 



INTRQPUFTIQN 



A. DEFINITION OF THE PROBLEM 

In today's -fast-paced world community, the logistics of 
assembling a group of experts for the purpose of resolving a 
particular problem has become a problem unto itself. 
Conflicting schedules, prohibitive distances, and the 
increasing frequency of group decision-making efforts are 
constant barriers to effective attacks on common problems. 
Even if such problems were easily surmountabl e , the 
importance and complexity of today's problems would require 
a decision based on the concensus of an expert group rather 
than the opinion of a single, stong-minded individual. 

B. THE NEED FOR THE COMPUTERIZED GDSS 

Managerial decision making has become increasingly more 
dependent upon computer -generated information. As a result, 
management is more cognizant of the capabilities and 
potentials of computer — based systems. The computer— based 
system has evolved from assisting individuals in making a 
decision to supporting and enhancing a wide range of group 
and organizational decisions. The question is how to 
effectively and efficiently design a distributed Decision 
Support System (DSS) to aid a group in defining, evaluating, 
modifying, and seeking consensus in deriving the criteria 
for a common problem. Recent literature in computer 
conferencing systems suggests that a computer-based Group 
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Decision Support System (GDSS) could: 

1. Reduce tension due to f ace-to-f ace communications, 

2. Promote equal parti ci pati on , and 

3. Favor -free and creative generation o-f ideas. 

C. SCOPE OF TOUCHSTONE 

CO-OP, a program recently developed at the Naval Post- 
graduate School, Monterey, California, was designed to 
assist in the pr i ori t i zat i on of previously-developed 

criteria. Touchstone, the program written as an adjunct to 
this thesis, is a prototype of a text-oriented, criteria- 
development system which may be utilized independently or as 
a "front— end " to the CO-OP program. Inasmuch as it is a 
prototype, there are necessary physical limitations to the 
number of problems, criteria, and people the system is 
designed to handle. 

While both Touchstone and CO-OP are stand-alone systems, 
Touchstone offers a solid baseline of developed criteria 
upon which CO-OP builds, and from which it processes a 
decision, using mathematical modeling. Touchstone is a 
self-contained system, with an on-line, on— screen "users 
manual" that provides specific information based upon the 
user's position and status in the program. Use of Touch- 
stone neither requires nor precludes the use of CO-OP, but 
these two systems complement each other in their methods of 
problem resolution. 
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D. ORGANIZATION OF THE THESIS 



Inasmuch as this thesis is project-oriented, the actual 
text herein is minimal, limited primarily to a description 
of the background -for, and the process o-P , putting the 
Delphi system on an electronic medium- The bulk of the 
information is contained in the source code found in 
Appendix E. It is the technique of implementing the text- 
orientation, the help screens, the communicative 
"Chatterbox", and the hierarchical text-manipulation, which 
is the essence of our efforts and our thesis- Touchstone is 
the thesis; this written effort is merely a support and a 
description of the true product of our research. 

E. FOCUS OF THE THESIS 

This thesis, and its accompanying computer program, 
focus on a particular aspect of group decision making- They 
develop a framework for guiding committee members to 
individually generate criteria for a collective problem, 
merge them together, and allow interactive negotiation and 
collective refinement of the set of criteria representing 
the problem- This concept is centered around the premise of 
the Delphi method of group decision-making and reflects the 
attempt of that method to provide anonymous and equal 
partnership in problem resolution- The peculiarity of the 
Touchstone system is its unique utilization of organized 
text processing without depending upon complex mathematical 
modeling to reach a conclusion. 
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F. OBJECTIVE 



Our objective is to provide the proper mix o-f computer 
assistance and creative -freedom -for the Touchstone users as 
they attempt problem resolution with the Delphi method- The 
program is developed to support individuals and groups 
having expertise in the management -field but not necessarily 
in the computer -field- It is our intent to create an 
automated group decision-making tool that will take 
pressure, both real and imagined, away -from the individual 
member serving on a committee, while not compromising the 
effectiveness o-f the committee as a whole- The system 
should allow the user to interact with other members o-f the 
committee, -free from the effects of those members' actions, 
prejudices, and mannerisms. 
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II. 



THE DELPHI METHOD OF GROUP DECISION MAKING 



A. BACKGROUND 



Research 
methodology 
descr i pti ons 
corporati on 
fundamental 



literature on the subject of the Delphi 
gives a wide variety of definitions and 
• The concept, developed primarily by the Rand 
beginning in the late 1960's, has some 
building blocks common to most versions: 



1. An individual who defines a particular problem. 

2. A group of experts gathered together to resolve a 
parti cul ar problem. 

3. A facilitator who collects the input from the 
experts, collates it, and gives the composite 
results back to the experts for further 

consi deration. 

4- Anonymity in the sense that the experts do not know 

the individual sources of the collective information, 
(although they may, in fact, know who else is in the 
group) - 

The purpose of the Delphi methodology is the elimination of 

external influences on group concensus and decisions. 

The idea is to improve the panel or committee 
approach in arriving at a forecast or estimate by 
subjecting the views of the individual participants to 
each other's criticism in way that avoids face-to-face 
conf rontation. CRef. 11 



It is by this technique that a free and open discussion of a 
problem may be implemented regardless of the personal i ti es , 
ranks, or prestige of the parti ci pant s. The solution to the 
problem, and little else, becomes the focus of the 
di scussi on. 
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B. COMPUTERIZATION OF THE DELPHI METHOD 



Translating the Delphi method to the computer can be a 
relatively logical process. Building blocks 1 and 2 (see 
II, A.) are essentially unchanged; -for building blocks 3 
and 4, the computer replaces the human involvement. Touch- 
Stone refers to the individual defining the problem, as the 
'problem invocator ', and to the experts as the 'committee 
members'. Through the Touchstone program, the computer 
becomes the facilitator, collecting and collating the expert 
input. The anonymity of the experts is adequately main- 
tained by the system to all but the problem invocator. 

The major advantage to automating the Delphi method is 
time. The Delphi method is lengthy and cumbersome when 
executed on a committee of any significant size. The 
computer allows committee members to be located around the 
world and still to have instant access to the ' f aci 1 i tator ' 
at any time of day or night. In this manner, problems may 
be resolved in days instead of months, and the need to 
physically assemble a group of experts to resolve a problem 
is all but eliminated. 



III. 



THE MODEL COMPONENT 



A. MODEL BASE FOR GROUP DECISION MAKING: ALTERNATIVES VS. 

CRITERIA 



Our framework for DSS includes modeling and model 
usage as one of three basic components, completely 
integrated with data base and dialog capabilities. This 
full integration is necessary to support deci si on— maki ng 
activities such as projection, deduction, creation, and 
comparison of alternatives. These activities require 
close interaction and rapid feedback between the decision 
maker and the computer, with strong and flexible control 
mechanisms. CRef. 2, p. 2761 



Alternatives are defined as the choices available for the 
resolution of a given problem; criteria are the guidelines 
to be used in making the final decision between those 
al ternati ves. Touchstone allows for the development of both 
of these important aspects of any decision, by allowing 
members to define, explain, discuss, re— define and agree 
upon a collective set of alternatives and criteria. Once 
this initial decision has been made, the remaining user 
responses and actions are the same for both. The initial 
decision of the committee member is to make the choice 
between developing alternatives or developing criteria. 

The Touchstone system uses the Model— Dialog link as 
described by Sprague and Carlston in that six basic steps 
are utilized: 

1. Invocation: user calls and starts the model 

2. Parameter request: program requests data or 
parameters 
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3. Parameter collection: user supplies data or 

par ameters 

4. Interrupt: not usually available other than 

unrecoverable terminate (break) or pause. 

5. Model completes run, notifies and presents results in 
a predefined -format or report. 

6. Return to step 1 -for another cycle if desired. 

[Ref. 2, pp. 274—2751 

B. PROBLEM INVOCATOR 

The major design factor for Touchstone revolves around 
the creation of the problem and the responsi bi 1 i t i es/1 i mi ta— 
tions designated to resolve that problem. It was determined 
early in the research for this project that at least one 
person needed to be responsible for identifying the problems 
and for necessary housekeeping chores. We established this 
'position' by looking at a normal face— to— face committee, 
and emulating the positions within the Touchstone System, 
making the "problem invocator" the committee chairman. The 
potential duties of the problem invocator have extensive 
ramifications and far reaching consequences. Initially, the 
invocator is responsible for naming the problem, providing a 
short but descriptive definition, and (optionally) expanding 
upon that definition to any length he feels necessary. He 
is also responsible for designating the committee members, 
adding and deleting members to any committee as indicated, 
and for removing completed problems from the system. Figures 
16—19 exhibit screen menus with options available to the 
invocator. Final printouts of committee results and 
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archival printouts of the Chatterbox -file are under his 
purview (see Figure 29). 

One o-f the most important decisions made by the 
invocator is that of committee member anonymity. The 
date/time/signature line in the Chatterbox (Chapter 6, 
paragraph D) may be modified to delete the automatic 
inclusion of the committee members' initials. In this 
manner, the interaction between members may be truly 
anonymous and in keeping with the spirit of the Delphi 
method of group decision-making. The use of the date/time 
signature stamp is two-fold, not only does it provide a 
reference point for committee members, it also allows the 
problem invocator to monitor the progress of the committee. 

C. COMMITTEE MEMBER 

The duties of the committee members are relatively 
simple to define. They are required to input their ideas 
and await further Touchstone system instruction at each 
level. Although the final product of their labors can be 
quite complex, the step-by-step methodology simplifies their 
efforts. 

One of the major concerns of the Delphi method was that 
committee members be allowed to reach a concensus without 
being intimidated by the leader/invocator, or other 
committee members CRef. 31. Psychological research has 
shown that intimidation may occur by the tone of a person's 
voice, or even a casual glance from a superior CRef. 43. In 
the case of the Touchstone system, the invocator defines the 
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problem, assigns members, and has total access over the 
system, but is unable to influence the committee members by 
any of his system actions- Also, the committee members are 
only able to influence other members by the strength of 



their ideas, not of their personality or position. 



LEVEL 0: 




Figure 3.1 Data Flow Diagram 
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LEVEL Is 




Figure 3.2 Data Flow Diagram 




IV. 



THE INTERFACE COMPONENT 



A. SCREEN DESIGN 

The original concept -for the screen design Tor Touch- 
stone was to use a 3— window screen which would incorporate 
the problem definition, the Chatterbox, and the criteria 
manipulation. It soon became evident that this technique 
would not provide adequate space for any of the above- 
mentioned functions. The use of pop— up windows became the 
most reasonable alternative. Commercial software was 
researched, but it was felt that RAM resident windows did 
not provide adequate flexibility for context-sensitive help 
screens. 

The use of multiple and/or "pop-up" windows was 
determined to be the most user-friendly method of providing 
communications and on— screen assistance. It was felt that 
simply refreshing the screen with the new screen, and then 
restoring it after the help or Chatterbox screen was 
through, was too distracting to the user. Employing windows 
allowed the user's main focus to remain on the problem 
screen, even when using the Chatterbox or the help screens. 

The present screen design utilizes a number of separate, 
interactive screens. The main program uses a single box 
with the Touchstone logo at the top of the box. Each of 
the other screens is individually labeled, depending upon 
its function. Smaller boxes for the help screen, problem 



19 



explanation and Chatterbox are layered onto the main screen. 
Any in-formation overlaid by these boxes is restored when the 
box is removed. The boxes are carefully positioned for the 
express purpose of minimizing the amount of current informa- 
tion hidden by the overlay. (See Figures 36-33). 

Screens are designed for maximum user effectiveness, 
keeping in mind, that a "busy" screen is often confusing. 
Menus are used as frequently as possible, limiting the 
number of choices to a minimum. The basic background 
colors are a light blue for all screens, with contrasting 
colors being utilized for special flags and pop-up windows. 
An example of this is the use of a red background for 
certain error messages. 

One of the special features of Touchstone's screen 
design is the Odometer, which tracks and displays the user's 
relative position in the Touchstone decision making process. 
It also indicates a Chatterbox entry that the current user 
has not viewed. Located at the bottom of main the screens 
the Odometer also contains instructions for the use of the 
Function Keys. (See Figure 35). 

B. DIALOGUE STYLE 

As previously mentioned, the program is developed to 
support individuals and groups who are novices in computers. 
The use of "special function" keys is kept to a minimum, 
with clear definitions as to their usage displayed in the 
Odometer. Thus the simplicity of Touchstone eliminates the 
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necessity for a manager or CEO to use a "computer chauffeur" 
for data input. 

C. ON-LINE ASSISTANCE 

Program assi stance from Touchstone is provided in two 
forms, the "Introduction" screen and the "Help" screens. 
The "Introduction" screen is an option presented at the 
beginning of each Touchstone session, and contains a 
general , 4-page overview of the program. 

The initial idea for the Help Screens was to implement 
an "automatic" screen, one which would appear when 
appropriate, without user action. Three categories of user 
expertise were defined, with correspondi ng levels of pop-up 
help windows. The user would indicate his ability level at 
the beginning of each session, following which the context- 
sensitive on-line help screens would appear as the 
programmers felt necessary. Subsequent research revealed 
that this idea was neither feasible nor desirable, from 
either the programmers' or the users' standpoint. 

The present design of the "Help" screens for Touchstone 
follows the basic premise used by some of today's more 
papular software. A single function key (F— 1) accesses one 
of the many pre-written help screens- Each screen is coded 
for access depending upon the user's location within the 
program. In this manner, the help screens remain current 
with the user and do not require a complex set of keystrokes 
on the user's part for access- The "help" text is 
frequently larger than the size of the screens, and a 



21 



scrolling capability is implemented to compensate -for 
di screpancy . 



thi s 



V. 



THE DATA COMPONENT 



A. DATA STRUCTURE/MANAGEHENT 

The primary purpose o-f Touchstone, that o-f criteria/ 
alternative development, forces it to rely almost completely 
on the manipulation of text rather than data- The data 
component of Touchstone functions as a vehicle for flags and 
arrays- Each individual user of Touchstone is given a 

separate file far each problem to which he is assigned. 
That file contains the user name, the problem name, the 
current status of the user within that problem, and the 
criteria/al ternati ves that have been developed- IMhen this 
file is created, an entry is made in the "master" file. 

Conversely, when a problem is concluded and the user files 
deleted, the master file is updated accordingly- These are 
the files dealing with text/data mani pul at i on - Files 

utilized by the help screens. Chatterbox , and problem 
explanation screens are all text files. The help screen 
files have been created by the programmers; the problem 
explanation files is (optionally) created by the problem 
invocator at the time a new problem is defined; the 

Chatterbox files are created and updated each time the 
Chatterbox is used- The problem invocator has the option to 
print out the Chatterbox files at any time he so desires. 
Data Management concerns itself with the recording, 
editing, and manipulation of text input for criteria and 



alternati ves. Data management -for Touchstone is based upon 
the complex alliance of two -fundamental cornerstones: Flags 
and Arrays- The -flags provide a "location map” for all 
members on a committee, allowing the program (and the 
problem invocator) to accurately monitor the progress and 
status of each problem resolution- Arrays provide the 
structure necessary to contain and control the free-f low 
text input vital to creative thought. The algorithm used 
for the marriage of these two bui 1 di ng- bl ocks gives a large 
degree of freedom to the user while maintaining the 
structured environment required by the computer. 

The manipulation of data is handled mainly by the 
extensive use of arrays- Data is initially input directly 
into a file. On the next user— access this data is brought 
up in the form of an array- This technique allows the 
sorting of individual files and, when required, the 
collating of mul ti pi e— user files- It also permits the user 
to 'edit' the text while reviewing his individual files. 
When mul tipi e-user files are collated, duplicate records 
are eliminated, and the array replaces the original file 
with a new, composite file of criteria. 

liani pul ati ng text data from a variety of individuals 
calls for the use of an intricate series of flags- Each 
committee member's file has a flag-set based on the position 
of that file within the program- At certain points, 
continuation in the program is dependent upon the flag set 
of all other members in the committee- In addition. 
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overseeing the progress of each problem resolution is an 
important task of the problem invocator. For these reasons, 
a separate master file was conceived, containing each 
problem name, each member of the committee dealing with each 
problem, and the current status of each member within a 
given problem. 

The unique procedure "GetTheKeys" provides a variety of 
options for the system- Each keystroke is processed 
individually allowing the length of the input to be varied 
by the calling procedure- In that manner the user is 
prevented from entering data whose length is in excess of 
the size of the data field. The possibility of inputting a 
string of 60 characters, when the data field was only 10 
characters long, is thereby eliminated- The reading of each 
keystroke also allows the function keys to be accessed at 
any time during the program, and during the review and 
editing of the text portion of the program, the special 
functions of the numeric keypad (i.e. arrows and paging 
keys) are activated. 

An important feature of the data management of Touch- 
Stone is that it works in background mode, manipulating 
data, opening and loading files, and functioning as a system 
controller. It is an typical example of the "Black Box" in 
action- The user inputs data and receives results while the 
intricate process of weaving the input into a proper output 
goes largely unnoticed- 



VI. 



THE COMMUNICATION COMPONENT 



A. OVERVIEW 

A main -focus of Touchstone is communication — 
communication among users, communication between the user 
and the problem invocator, and user communication with the 
program itself. Without this intricate network of 
communication, the entire fabric of Touchstone would be 
1 ost . 

B. TEXT EDITING 

Inasmuch as Touchstone is highly involved in text 
manipulation, a variety of techniques in performing this 
manipulation was necessary to achieve our overall purpose. 
Once again, it was our goal to provide as much freedom as 
possible for the user while maintaining the necessary degree 
of system integrity. The concept of using a form of 
wordprocessi ng to input data is expected to be the most 
"user-friendly" method of inputting and manipulating data. 
Each keystroke is read and manipulated by our program. This 
practice allows the function keys and special keys to be 
programmer— defined and available throughout the system. 
Also, the on-line help-screens are automatically provided, 
progressing throughout the program. 

Word-processing indicates the capability to block copy, 
move text, read to and from files, as well as text 
manipulation. Touchstone's version of "word-processing" is 
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really a text editor, allowing tor text input, erasure, 
scrolling, paging, and home/ end— of — f i 1 e movement. Three 
specific versions o*f text— editing are utilized in Touch- 
Stone, each necessitated by the very different conditions 
under which it is used. 

The expanded problem explanation used by the problem 
invocator is a straight text editor employed when a problem 
is first described. Once invoked, a detailed explanation is 
written to file for later recal 1 by the committee members. 
Full text manipulation is possible only by the invocator; 
committee members are limited to a read— only status. In 
this manner , only the problem invocator has the ability to 
define the probisn, ensuring that each committee member is 
using the same baseline information. 

Although previous Chatterbox entries are available for 
review, text editing in the Chatterbox is available only at 
the specified point at the end of the file. Action in the 
review mode is limited to scrolling and paging. Once an 
entry has been saved, it is not available for editing. By 
limiting editing access to the entry being made, a 
"permanent" record of Chatterbox entries may be made. 

Text— editing in the main section of the program is 
limited to single-line input. The length of each line is 
location sensitive and specifically defined. This method 
allows for a wide range of functions, including the constant 
access to help and Chatterbox screens, as well as the 
ability to input string and numerical variables employing 
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the same procedural call. Elimination of all "READ" and 
"READLN" calls was the unique contribution of this procedure 
and the basis for an increased elegance in programming. 

C. HELP SCREENS 

Help screens are important for the system to be 
informative. Help screens are discussed in Chapter IV, 
paragraph C. 

D. PROBLEM EXPLANATION SCREEN 

The problem invocator communicates with the committee 
members via the "problem explanation" box, accessed with the 
F— 2 key. During the initial creation of the problem, the 
invocator is prompted to give a detailed explanation of the 
new problem. If he elects to do so, a file of up to 100 
text lines is made available to him. The committee member 
then has a custom-made information file for each problem on 
which he is working. Text manipulation is "read" and 
"write" for the problem invocator (at the time of problem 
creation only) and "read-only" far the committee member. 
Since the problem explanation may be considerably larger 
than the problem explanation screen, scrolling and page 
up/down features are available to the user. 

E. THE CHATTERBOX 

The primary purpose of the Chatterbox is to promote the 
informal exchange of information among committee members. 
It has remained unchanged in its basic concept throughout 
the design and coding. However , 
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of the many technical 



enhancements considered, those implemented were based 
primarily upon user acceptance. 

Chatterbox differs -from a conventional notepad in a 
number of ways. As mentioned before, in order to prevent 
“malicious" erasure of text, previous entries of text cannot 
be changed. Also, each individual problem has its own 

unique, automatically accessed. Chatterbox. Anytime the 
user leaves the Chatterbox, the file is saved unless no 
entry has been made. Any entry made in the Chatterbox is 
date/time/signature stamped providing an automatic record of 
the user. The problem invocator has the option of 

eliminating the signature from the viewed stamp for any 
given problem. 

Location of the Chatterbox was the source of much 
discussion. The Chatterbox is located at the right— hand 
side of the screen, in order to leave important information 
residing in the main screen visible to the user. Ideally, 
it would be nice to provide a movable window; however, in 
this version, the location of the Chatterbox is fixed. 

Designed to be used on a single computer or in a 
network. Chatterbox has a few unique features. 

1) Only one person may write to Chatterbox at a given 
time, but more than more person may use it on a 
read— only basis. 

2) The last 80 text lines of a given Chatterbox file 
are read into the Chatterbox array, with capability 
to add up to 40 lines of new text. However, a flag 
attached to the line counter prevents writing to 
any area except the last forty lines. In that 
manner , only new information may be edited. 

3) One of the special features of the Chatterbox is to 
locate the user, upon re-entry, in the place 
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(time/date), where he last logged out of the 
Chatterbox. This -feature allows him to check the 
messages that were entered after the last logout. 
Consequently, all new entries are immediately 
available -for his review. 

4) The line counter , in the upper right hand corner o-f 
the Chatterbox , allows tor quick location reterence 
when browsing. 

5) Standardizi ng the line number between the read- 

write and read-only sections of Chatterbox made 
this delineation easier to implement. The 

appropriate placement of the text retrieval from 
the files was the primary key to controlling this 
procedure. 

There were two specific issues which were considered, 
but rejected as part of the final design: 1) The 

imposition of time limits for a person using the Chatterbox 
was discussed but not implemented. It was felt that the use 
of a forty line limit on each entry was to be a sufficient 
constraint. 2) We also ruled out the possibility of 
importing data files into the Chatterbox. Such a situation 
would reduce the reading capability of the user, and fill 
the Chatterbox with excess information. 

The Chatterbox is an integral part of the Touchstone 
system, being as important as the internal algorithms that 
aid the users in making a decision. Communication, as 
always, is vital to any decision-making process, and the 
Chatterbox enhances this aspect of the system. 
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VII 



I MPLEMENT ATI QN OF TOUCHSTONE 



A - HARDWARE/SOFTWARE 

Touchstone was developed on a Microsoft-based DOS 
computer with 640K RAM and a color card- Touchstone can be 
processed on a dual disk -floppy drive system or a single 
floppy disk, with a hard disk system- Each floppy disk 
drive should be 360K RAM. 

The Microsoft Disk Operating System utilized was version 
3.1- The Touchstone System was written in Turbo Pascal 
version 3-01. No other software packages were employed in 
the final version of Touchstone- The system is comprised of 
four separate programs in the form of command files: 

1) ATOUCH-COM 

2) BTOUCH-COM 

3) CTQUCH.COM 

4) FLAGSET-COM. 

These files are incorporated in a batch file called TS.bat. 
Each command file is basically a driver program, with 
numerous include files- These include files are listed in 
Appendix E- Documentation is done internally at the begin- 
ning of each procedure- Internal documentation lists the 
foil owi ng : 

Procedure name. 

Pr ogr am supported . 

Local variables used. 

Global variables used. 

Arrays used. 

Files accessed- 



External Calls. 

External filters (include files) used. 

Where the procedure is called from. 

Purpose of the procedure. 

The effort expended (manhours) was as follows: system 

analysis and design, 100; research and thesis preparation, 
150; coding, testing, and debugging: 700. 
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VIII. CONCLUSIONS 



Touchstone, originally conceived as a criteria 
development tool for another DSS program ("CO-OP”), 
subsequently evolved into a stand alone program. As a non- 
mathemati cal , tex t— or i ented GDSS, this program has entered a 
new area of computer support for making decisions- Although 
not thoroughly tested in a networking environment, the 
potential for such a use was an integral part of the design 
consi derati on and was incorporated in the final product. 

Touchstone works. It provides a vehicle for criteria 
development in a group environment using the Delphi method, 
creating a novel technique of computer assistance. The 
objective of providing a proper mix of computer assistance 
and creative freedom in the explanation and analysis phase 
of the problem solving process, has been achieved- 
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DATA DICTIONARY 

A, 8, I, J, W, X, Y, Z: Various integer counters used 

throughout the system. 

L, M and N: Integers that are summed and value passed to 

variable checkpoint. 

ACTIVEPROBLEMFILE: file of PROBREC. 

ALT: Single character used in identifying the file as an 

Alternative or Criteria, to be printed. 

ALTERNATIVE: A single character , ' A ' or 'C* for Alterna- 

tives or Criteria, used for assignment or comparisons. 

ANONYMOUS: Boolean expression used in the chatterbox . 

When created, the problem invccator has the option to make 
communications anonymous from other committee members. 

AUTHORIZED: Boolean expression, if true, allows the system 

to execute, if false, terminates the system. 

CH, CHA: Single characters used for YES/NO type questions. 

CHANGEFLAG: Boolean variable responsible for setting flags 

appropriately depending on whether the user is in "Alterna- 
tives" or "Criteria" . 

CHANGEREC: A single character used to confirm whether the 

problem is an Alternative or Criteria. 

CHATRFILE: 12 character string denoting the chatterbox file 

to be used. 

CHATOK: Boolean expression that controls the use of the 

chatterbox utility. 

CHECKCHANGE: A single character used to confirm whether the 

problem is an Alternative or Criteria. 

CHECKPOINT: Integer denoting the sum of the first three 

flags in this record. These records are sorted on this 
field to keep them in order according to the level of the 
data, i.e. , 111 would equate a piece of data under the 

first major criteria, under the first sub-criteria. 



CHECKS i A E: Is a single character used to track the user's 

position in the system. 

CHKFLAG1 , CHKFLAG2 , and CHKFLAG3: Integers used to number 

the ci rfersnt levels or alternatives/criteria. 

CHOICE: A single character, 'A' or 'C' for Alternatives or 

Criteria, used for assignment or comparisons. 

CHT : Single character utilized for error trapping 

procedures. 

CLEARIT: Integers used for tracking the arrays, advanced 

once for each record. 

CODEARRAY: String of 12 characters used to encode an decode 

passwords . 

CODENAME: String variable used for encoding and decoding 

user passwords. 

COUNT , COUNTED, COUNTER: Integers used for tracking the 

arrays, advanced once for each record. 

CRITARRAY: An array of the records in the format of CRT REC - 

CRITDEF: String of 53 characters defining the above 

variable CRITNAME. 

CRITERIA: Used in conjunction with the record CRIREC. 

CRITLIMIT: Integer denoting the maximum number of ai tar na- 

il ves/critsri a ail owed . 



CRITNAME: String of 10 characters denoting criteria/altsr- 

natives name. 



DATE: A 


stri ng 


of 


12 characters 


passed to a 


file 


as 


t h e 


day, men t 
accessed . 


h and 


year 


for tracking 


the last time a 


file 


was 


DATELINE: 


String 


of 


12 characters 


which gives 


the 


1 ast 


date 



that the file was accassec. 

DEFINITION: String of 53 characters which gives the short 

version of the problem definition. 

DOUBLECOUNTED: An integer counter used during the merging 

of files process. 

FILECHECK: Boolean expression used when checking the 

validity of a filename- 
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denoting the drive the 



data 



FILEDRIVE: Single character ,, 

-filee reside on. 

FLAGCHOICE: A string of 1 character used to set users 

probl emt 1 ag . 

FLAGC0UN7: Integers used -for tracking the arrays, acvancsd 

once for each record - 

FLAGEND: Integer that counts ail riles with the same 

problem name and the same HFlag setting. 

FLAGGED: Single character used to check committee member 

status prior to merging -files. 

FLAG!: Integer denoting level 1, major criteria. 

FLAG2; Integer denoting level 2, sub-critaria. 

FLAG3: Integer denoting level 3, tertiary criteria. 

HELPDRIVE: Single character denoting the drive the help 

files reside on. 

HELPER: Single character that indicates the active help 

screen . 

HELPSIZE: Integer parameter passed to determine the size of 

the helpscreen. 



INPUTSTRING: Used with the variable STRINGARRAY, as a 

passed parameter to the procedure GetTheKeys. 

INVOCATOR: A single character either a # W # or ‘ M ' usee to 

determine whether the user is a problem invccatcr <M) , or a 
commi it ee member \C) . 

KEEPTOGETHER: An integer counter used during the sorting 

routine to keep the records in the various levels in the 
order in which they were entered. 

KRI7ERI AFILE: file of CRIREC. 

LIMID: An integer parameter passed to a procedure esnot: nc 

the number of records in an array. 

LIMMIT: Integer set to the maximum number of records in an 

array . 

LINEMARK: Boolean expression used to advance line counter 

when displaying data on the screen. 

MARKER: Integer used in conjunction with the qotcXY 

whan positioning data on the screen. 



call 



MEMBER: String of three characters which indicates that 

there is a file in the DOS directory with the extension 
using this members name. 

MEMBERS: Used in conjunction with the record PROBREC. 

MGVEOVER: Integer used in conjunction with the gotoXY cal 1 

for positioning data on the screen. 

MOVEX: Integer used with the gotoXY statement positioning 

data cn the screen. 

NAMES: Variable used with the record CRIREC and array 

CRITARRAY. 

NAMESTRING: A string of three characters that is used as 

the extension when recalling the user's file. 

NEWCRITLIMIT: Integer denoting the maximum number of alter- 

natives/ criteria all owed. 

NEWLIMI7: An integer limiting the number of entries that 

can be made for al ternati ves/cr i ter i a. 

NEWNAME: 3 character string used when verifying filenames. 

NEWPROB: Single characters used for YES/NO type questions. 

NEWSTRING: 12 character string denoting the file to be 

used . 

NUM: Integers used for numbering the criteria/aiternati ves 

when displayed on the screen. 

NUMMEMS: Integer that tracks the number of members on a 

particular committee. Minimum value of 2 and maximum value 
of 15. 

□NCECGUNTED: A boolean expression used in the merging 

process. 

PRINTONE: Boolean expression used when printing alterna- 

te ves/ cr i ter i a. 

PROBARRAY: An array of the records in the format of PRGBREC. 

PROBLEM: String of seven characters which indicates that 

there is a file in the DOS directory beginning with this 
str i ng . 

PROBLEMFLAG: Single character used to track the status of 

the user who is logged on to Touchstone. 



PRQBNANE: A string o f seven characters that is used as the 

-first seven letters when recalling a user -file. 

PR0B5: Variable used with the record PRQBREC and array 

PRDBARRAY. 

PT1, P72, PT3 and PT4: Integers used as points when de-fi- 

ning the various windows used in the svscem. 

QUITFLAG: Integer used in moving from level to level in the 

al ternat i ves/cr i ter i a data entry. 

GUITFLG1, GUITFLG2, QUITFLG3: Integers tracking the number 

of al ternati ves/cr i teri a at the various levels. 

RECOUNT: Integer used in positioning the pointer when wri- 

ting to a users problem file. 

SCROLLIT: Bool ean expression that controls the use of the 

arrow keys, sc that they may only be used during certain 
portions of the program. 

SECNUM: Integers used for numbering the criteria/alterna- 

tives when displayed on the screen. 

SELECTED: Integers used for tracking the arrays, advanced 

once for each record. 

SHOWNE: Integer used in moving from level to level in the 

al ternati ves/cr i ter i a data entry. 

STARTMERGE; A boolean expression, that, when true allows 
ail files with the same problem name to be merged into one. 

STARTUP: Boolean expression used in several procedures to 

check the validity of the file requested or to check for 
dupl i cati on . 

STATFLAG: Character that tracks where the user is in the 

system. 

STRINGARRAY: An array of 1 to 59 characters, used in 

conjunction with the procedure GetTheKeys. 

STOPGAP: Boolean expression used to stop al ternati ves/ 

criteria input beyond a predeter mi ned limit. 

STOPPROG: Boolean expression, if true terminates a proce- 

dure or the entire program, depending on when it is toggled. 

TENPFILEs A temporary file using text vice records. 

TEMPMAME: String variable used for encoding and decoding 

user passwords. 
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THRNUMs Intscers used for numbering the cri ter i a/al ter na- 
tives when displayed on the screen. 



TRACK1 : Integer denoting number a f records in an array . 

USERCODE; 3 character code used to verify password. 

WEEDDEF : Boolean ex pres si on used to activace the F3 

when the program goes past the problem selection stage- 
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APPENDIX 3 



FILE STRUCTURE 



PROBREC: Is the master record that holds the roil owing 

in-formation on all or the problems in the system- The 
following variables comprise this record: 

CHECKCHANGE: A single character used to confirm whether the 

problem is an Alternative or Criteria. 

CHECKSTATE: Is a single character used to track the user's 

position in the system. 

CHOICE: A single character, 'A' or 'C' for Alternatives or 

Criteria, used for assignment or comparisons. 

DATELINE: String of 12 characters which gives the last date 

that the file was accessed. 

DEFINITION: String of 38 characters which gives the short 

version of the problem definition. 

MEMBER: String of three characters which indicates that 

there is a file in the DOS directory with the extension 
using this members name. 

NUMMEMS: Integer that tracks the number of members an a 

particular committee. Minimum value of 2 ana maximum value 
of 13*. 

PROBLEM: String of seven characters which indicates that 

there is a file in the DOS directory beginning with this 
string . 



QBIBiGs 

There is 
speci f i c 



Is a record 
one file 
probl em. 



i nf ormat i on : 



that is contained in a file 
for each committee member 
The record contains the 



in DOS. 
for each 
foil owi nc 



CHECKPOINT : Integer 

flags m this ^ecor 
field to keep them 
data , i . e. , 111 

first major criteria. 



denoting the sum of the first three 
d- These records are sorted on this 
in order according to the level of the 
would equate a piece of data under the 
under the first sub-criteria. 
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CRITDEF: String of 58 characters defining the above 

variable CRITNAME. 

CRITNAME: String of 10 characters denoting criteria/alter- 
natives name. 

FLAG1: Integer denoting level 1, major criteria. 

FLAG2: Integer denoting level 2, sub-criteria. 

FLAG3: Integer denoting level 3, tertiary criteria. 

STATFLAG: Character that tracks where the user is in the 

system. 
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APPENDIX C 
SCREEN FORMATS 

FIGURE 1 
TITLE SCREEN 



I uuCnb ruYvc. 



A Criteria Devel oornerrt Proprarn 
for Group Decision Support Systems 

M i cn ae I £ - 'mbs 2 ey 
Kooen: T. wooioridqe 



N ava- yostq r a a a axe -r. c n o o ± 
Mont e rev , u a i i forn i a 
i SBS 
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FIGURE 2 

THESIS ADVISOR SCREEN 
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DE PA RT i'lEN T 

Tnesis Advisor 

X u an 7 un a Bui, P n « D . 

N a v a i Post q r aouaue Sen o o 1 
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FIGURE 3 
DATE SCREEN 



TOUCHSTONE 

THE CORRECT DATE IS VERY IMPORTANT TO THE 
PROPER FUNCTIONING OF TOUCHSTONE? 

Jari £S, 1387 

Is tms date correct? Y 



FIGURE 4 

INTRODUCTION OPTION SCREEN 



TOUCHSTONE 



WOULD YOU LIKE AN INTRODUCTION TO TOUCHSTONE? <Y/N> * 
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FIGURE 5 

INSTRUCTION SCREEN #1 



T GOC'HST ONt 

* INTRODUCTION & INFORMATION * 

The TOUCHSTONE proqrarn is designed to assist you m 
developing functional and meaningful group criteria for 
a Group Decision Support System- Utilizing the TOUCHSTONE 
program, you will be able to condense a large list of 
spont aneously- considered criteria into a compact, well- 
defined, 6 ft GuP— SELECTED set of criteria. 

< PRESS ANY r\EY TO CONTINUE) 



FIGURE 6 

INSTRUCTION SCREEN #2 

i Q uChSTOnE 1 

*• INTRODUCTION & INFORMATION (continued) * 

These criteria will oe umouelv flesipned to assist you in 
resolving your current proDlera, whatever it might be. 

Inst ruct ions, specific to each portion of the program, may 
be called at any time bv pressmp the <F— 1> ("HELP" ) kev. 
Communication between "committee members" is accomplished 
via the "Cnatteroox", an electronic notepad wmcn is 
< PRESS ANY KEY Tu CONTINUE) 
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